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Description 

This invention relates to a method of encoding dig- 
ital information in machine readable form onto a record- 
ing medium. 

Plain paper stilt is a favored recording medium for 
storing and transferring human readable information, 
but the emergence of electronic document processing 
systems has made it evident that the functional utility of 
plain paper and other types of hardcopy documents 
could be enhanced significantly if the human readable 
information they normally convey was supplemented by 
writing appropriate machine readable digital data on 
them. This machine readable data would enable the 
hardcopy document to actively interact with such a doc- 
ument processing system in a variety of different ways 
when the document is scanned into the system by an 
ordinary input scanner. See, for example, our copending 
European Patent Applications EP-A-0 469 868, EP-A-0 
459 792 and EP-A-0 459 793. 

As a general rule, digital data is recorded by writing 
two dimensional marks on a recording medium in ac- 
cordance with a pattern which encodes the data either 
by the presence or absence of marks at a sequence of 
spatial locations or by the presence or absence of mark 
related transitions at such locations. Ordinary magnetic 
and optical digital data recording conform to this style of 
encoding. Furthermore, the bar-like codes which have 
been proposed previously for recording digital data on 
paper also conform to the above-described encoding 
style. See US-A-4,692,603 on "Optical Reader for Print- 
ed Bit-Encoded Data and Method of Reading Same," 
US-A-4,728,783 and US-A-4,754,127 on "Method and 
Apparatus for Transforming Digitally Encoded Data into 
Printed Data Strips," and US-A-4,782,221 on "Printed 
Data Strip Including Bit-Encoded Information and Scan- 
ner Contrast." 

Considering the aforementioned bar-like codes in 
some additional detail, it will be seen that their visual 
appearance is highly variable because it is data depend- 
ent, so they tend to have a mottled appearance. This 
mottling is a readily discernible departure from the 
clean, crisp appearance of high quality printed docu- 
ments, so it may be aesthetically objectionable to some 
observers. Furthermore, another drawback of these 
bar-like codes is the overhead that they contemplate. In 
particular, as taught by the above-identified patents, this 
overhead includes the registration marks which are pro- 
vided for preserving the data clock, as well as the header 
information which is provided for describing the organi- 
zation of the encoded data, such as the number of bits 
encoded along a given line of code. 

WO86/00445 discloses a system for recognizing 
the content of a communication in a symbolic language 
and composed of plural glyphs arranged in a predeter- 
mined order, each glyph being the smallest (lowest) in- 
formational unit of the language. The system includes a 
device for inputting a stream of data indicative of the 
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plural glyphs, such as formed in a page of text. That 
stream is input into a storage means. The stored data 
is horizontally segmented into discrete lines of text and 
is then vertically segmented into individual glyphs. Each 
s individual glyph is assigned a unique identifier, whereby 
all substantially identical glyphs are represented by the 
same identifier. The identifiers are arranged in a se- 
quence corresponding to the sequence in which the 
glyphs appeared in the communication, thus represent- 
10 tng glyph 'words'. The system then applies decryption 
routines which include general cryptographic tech- 
niques to the identifiers, their sequences and their inter- 
relationships to determine the equivalent symbol of lan- 
guage corresponding to each identifier. Once the sym- 
75 bol of language corresponding to each identifier has 
been determined, the machine code equivalent (i.e., 
code capable of being 'understood' and utilized by an 
electronic computer) is substituted for each identifier, so 
as to provide a machine readable code representation 
20 of the communication, e.g., page of text. 

US-A-4,754,127 discloses a data strip (2) of prede- 
termined size made (a) by determining the total nibbles 
of digital information to be encoded and the maximum 
number of integral nibbles per data line (14), using pre- 
25 determined minimum dibit dimensions, after allowing for 
parity checks, alignment guides (32,36), and a start line 
(28), (b) by increasing the dibit dimensions to achieve 
the predetermined size, and adjusting the bit size to ac- 
count for ink spread, and (c) by preparing a reader in- 
30 struction header (1 6) contain ing coded specifications as 
to the data strip format. An associated printer (64) prints 
the data strip (2) with a header (16) and a data portion 
(12) in the determined format. Each code line being of 
equal amount of black surface area. 
55 It, therefore, will be evident that there is an urgent 
need for relatively efficient, visually improved codes for 
recording digital data on plain paper and other types of 
hardcopy recording media, especially for applications in 
which such machine readable data is to be recorded in 
40 visual juxtaposition with human readable information. 
Furthermore, it will be appreciated that there is a need 
for efficient and reliable techniques for recovering digital 
data from such codes. Moreover, inasmuch as images 
carried by hardcopy documents often are replicated, 
45 such as by photocopying and by facsimile reproduction, 
it will be apparent that it would be very beneficial to have 
data encoding and decoding techniques that can toler- 
ate a significant amount of image distortion. 

In response to the foregoing and other needs, the 
50 present invention provides a method of encoding digital 
information in machine readable form onto a recording 
medium wherein the information comprises digital val- 
ues of bit length n, as set forth in claim 1 . 

The invention also provides self-clocking glyph 
55 shape codes for encoding digital data in the shapes of 
glyphs that are suitable for printing on hardcopy record- 
ing media as set forth in claim 6. Advantageously, the 
glyphs are selected so that they tend not to degrade into 
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each other when they are degraded and/or distorted as 
a result, for example, of being photocopied, transmitted 
via facsimile, and/or scanned-in to an electronic docu- 
ment processing system. However, the broader aspects 
of this invention are directed toward codes composed 5 
of discriminate glyphs, without specific limitation to the 
amount of image degradation and/or distortion the 
codes can tolerate. Moreover, the glyphs are composed 
of printed pixel patterns containing the same number or 
nearly the same number of ON pixels and the same io 
number or nearly the same number of OFF pixels, such 
that the code that is rendered by printing such glyphs 
on substantially uniformly spaced centers appears to 
have a generally uniform texture. In the case of codes 
printed at higher spatial densities, this texture is likely is 
to be perceived as a generally uniform gray tone. 

Still other features and advantages of this invention 
will become apparent when the following detailed de- 
scription is read in conjunction with the attached draw- 
ings, in which: 20 

Fig. 1 is a simplified block diagram of an electronic 
document processing system for carrying out and 
taking advantage of the various aspects of the 
present invention; 25 
Fig. 2 is a functional block diagram of a typical proc- 
essor/printer interface for the document processing 
system shown in Fig. 1 ; 

Fig. 3 is a coding diagram for illustrating the bit en- 
coding that is provided by a relatively simple self- so 
clocking binary glyph shape code composed of ro- 
tationally variant glyph shapes; 
Fig. 3A is another coding diagram for illustrating the 
bit encoding of binary data in a rotational ly invariant 
glyph shape code; 35 
Fig. 3B depicts typical data cell structures, as well 
as typical printed pixel patterns for rotational ly var- 
iant glyph shapes of the type shown in Fig. 3; 
Fig. 4 is high level functional flow diagram of a first 
glyph code decoding process; 40 
Fig. 5 is a more detailed flow diagram of the glyph 
center locate, label and sort phase of an implemen- 
tation of decoding process shown in Fig. 4; 
Fig. 6 is a bitmap image of labelled glyph center lo- 
cations that are candidates for recalibration by the *s 
optional calibration process shown in Fig. 5; 
Fig. 7 is a relatively detailed flow diagram of the 
glyph read/error detect phase of the aforemen- 
tioned implementation of the decoding process 
shown in Fig. 4; 50 
Figs 8 and 9 illustrate pixel search regions that are 
suited for use in decoding relatively low and rela- 
tively high density glyph codes, respectively; 
Fig. 10 is a high level functional block diagram of 
system wherein glyph shape encoding and decod- ss 
ing is used for data containing error correction 
codes (ECC); 

Fig. 11 is a functional block diagram of a morpho- 



logical filtering process for filtering a scanned-in bit- 
map image of a glyph code to isolate the ON pixels 
at or near the centers of the glyphs through the use 
of large filters which are configured in accordance 
with the periodicity of the glyph code image; 
Fig. 12 is a bitmap image of a typical glyph code; 
Fig. 13 is a bitmap image illustrating the effect of 
applying the filtering process shown in Fig. 1 1 to the 
bitmap image shown in Fig. 12; 
Fig. 14 is another bitmap image to illustrate the ef- 
fect of iterativety reapplying the second level filter- 
ing of the filtering process of Fig. 11 to the bitmap 
image shown in Fig. 13; 

Fig. 15 is a functional block diagram of an iterative 

second level filtering process; 

Fig. 16 is a bitmap image of a glyph code filtered by 

an alternative morphological filtering process for 

spatially separating the glyph centers; 

Fig. 17 illustrates a bounding box expansion of the 

pixel patterns within the bitmap image shown in Fig. 

16; 

Fig. 18 is a bitmap image showing the isolation of 
the glyph center pixels that can be achieved, in the 
case of relatively low spatial density glyph codes, 
by identifying the centers of gravity of the individual 
glyph related pixel patterns within the bitmap image 
shown in Fig. 16 or by performing a thinning process 
on those patterns or on their bounding box expan- 
sions as shown in Fig. 17; 

Fig. 1 9 is a functional block diagram of a preliminary 
morphological filtering process that utilizes large fil- 
ters for increasing the spatial separation of the 
glyphs of higher spatial density glyph codes; 
Fig. 20 is a functional block diagram of a morpho- 
logical bitmap image repair process that may be 
employed for restoring ON pixels to glyph center lo- 
cations when the filtering process of Fig. 1 9 creates 
holes in the bitmap at those locations; 
Fig. 21 is a bitmap image of the glyph centers of a 
relatively high density glyph code, such as may be 
produced by performing a thinning process on the 
bitmap shown in Fig. 17 or on a bitmap produced 
by the image repair process of Fig. 20; 
Fig. 22 is a functional block diagram of an iterative 
morphological thinning process that may be em- 
ployed for producing the bitmap image shown in 
Fig. 21; 

Fig. 23 is a functional block diagram of a morpho- 
logical process for isolating glyph center pixels 
through the use of small, weakly matched hit-miss 
filters; 

Fig. 24 is a functional flow diagram of a decoding 
process which utilizes convolution filtering of the bit- 
map glyph code image for locating the centers of 
the glyphs in the bitmap image space and for clas- 
sifying the glyphs in accordance with their shapes; 
Figs 25A and 25B illustrate the results of convolving 
unweighted and weighted filters, respectively with 
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a glyph shape that is strongly matched by the filters; 
and 

Fig. 26 is a fragmentary flow diagram for illustrating 
a modified embodiment of the decoding process 
shown in Fig. 24. 

While the invention is described in some detail here- 
inbelow with specific reference to certain embodiments, 
it is to be understood that there is no intent to limit it to 
those embodiments. On the contrary, the aim is to cover 
all alternatives, modifications, and equivalents falling 
within the scope of the invention as defined by the ap- 
pended claims. 

A. An Exemplary Environment 

Turning now to the drawings, and at this point es- 
pecially to Fig, 1 , there is shown an electronic document 
processing system 21 to illustrate a typical environment 
for this invention. In keeping with standard practices, the 
document processing system 21 comprises a digital 
processor 22 having a main memory 23 and a mass 
memory 24, an input scanner 25 for scanning digital rep- 
resentations of selected hardcopy documents into the 
processor 22, and a printer 26 for printing hardcopy ren- 
derings of selected ones of the files that are listed on 
the file directory (not shown) of the processor 22. Fur- 
thermore, there is a user interface 27 for enabling a user 
to interact with the processor 22, the input scanner 25, 
and the printer 26. 

As will be understood, the user interface 27 collec- 
tively represents the input devices through which the us- 
er enters control instructions for the input scanner 25 
and for the printer 26, as well as the image editing and 
manipulation instructions for the processor 22. Addition- 
ally, the interface 27 represents the output devices 
through which the user receives feedback with respect 
to the actions that are taken in response to the instruc- 
tions that are entered by the user or otherwise, such as 
under program control. For example, the user interface 
27 generally includes a keyboard or the like for entering 
user instructions, a monitor for giving the user a view of 
the process that is being performed by the processor 
22, and a cursor controller for enabling the user to move 
a cursor for making selections from and/or for entering 
data into a process that is being displayed by the monitor 
(none of these conventional components is shown). 

The illustrated document processing system 21 is 
centralized, so it has been simplified by assuming that 
all control instructions and all image editing and manip- 
ulation instructions are executed by the processor 22 
under program control. In practice, however, the execu- 
tion of these instructions may be handled by several dif- 
ferent processors, some or all of which may have their 
own main memory and even their own mass memory. 
Likewise, either or both of the input scanner 25 and the 
printer 26 may have its own user interface, as indicated 
by the dashed lines 28 and 29, respectively. Indeed, it 
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will be evident that the document processing system 21 
could be reconfigured to have a distributed architecture 
to operate with a remote input scanner and/or a remote 
printer (not shown). Data could be transferred from and 
s to such remote scanner and printer terminals via dedi- 
cated communication links or switched communication 
networks (also not shown). 

Customarily, the input scanner 25 is a bitmap scan- 
ner which scans the image of each hardcopy input doc- 
ument at a predetermined spatial resolution of, say, 300 
s.p.i. x 300 s.p.i. (spots/inch) (about 12 spots per mm). 
In operation, the scanner 25 converts the individually re- 
solved picture elements (commonly called "pixels" or 
"pels") of the scanned image into corresponding digital 
values and assembles those digital values to produce a 
data structure (known as a "bitmap image") which pre- 
serves the spatial relationship of the pixels to which the 
scanned-in values pertain. Although the following de- 
scription focuses on applications in which the scanner 
25 is a black-and-white scanner for converting the pixels 
of the scanned-in image into single bit digital values (i. 
e., "1 M or "0"), it will be understood that it could be a gray- 
scale scanner for converting the pixels into multi-bit val- 
ues. Furthermore, it will be evident that the scanner 25 
could capture a bitmap image of a document or the like 
through the use of a video pick-up device and a so- 
called video "frame grabber", together with appropriate 
thresholding logic if needed. 

The printer 26, on the other hand, generally is a so- 
called bitmap printer for mapping the digital values of a 
bitmapped image file into the spatially corresponding 
pixels of the image it prints on a suitable recording me- 
dium, such as plain paper. The processor 22 may be 
configured to manipulate and store bitmapped image 
files and to transfer such files on demand to the printer 
26. Alternatively, however, as shown in Fig. 2, the proc- 
essor 22 may include a PDL (page description lan- 
guage) driver 31 for transferring to the printer 26 PDL 
descriptions of the electronic document files that are se- 
lected for printing. Thus, the printer 26 is illustrated as 
having a PDL decomposer 32 for decomposing such 
PDL descriptions to produce corresponding bitmapped 
image file. Still other types of printers and processor/ 
printer interfaces will suggest themselves, but it will be 
assumed for purpose of the following discussion that 
tine printer 26 is a bitmap printer that receives PDL files 
from the processor 22. 

B. Glyph Shape Encoding 

To carry out this invention, there is a glyph encoder 
33 for causing the printer 26 to print machine readable 
digital data glyphs on the recording medium, either 
alone or in juxtaposition with human readable informa- 
tion. For certain applications the glyph encoder 33 may 
be co-located with the processor 22 for inserting glyph 
encodings into the electronic document files prior to the 
translation of such files into PDL descriptions. But, for 
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other applications, it may be necessary or desirable to 
have the glyph encoder 33 insert the glyph encodings 
into the raster formatted bitmapped image file that is pro- 
vided for the printer 26. PDL descriptions of glyph shape 
encoded data may take several different forms, includ- 
ing encapsulated bitmap representations of the code in 
which such data is encoded, font descriptions and layout 
locations for bitmap representations of the individual en- 
coded glyph shapes (assuming that such bitmaps exist 
on or are down loadable to the font directory of the print- 
er 26), and bit-by-bit descriptions of the bitmaps for the 
encoded glyph shapes. 

More particularly, in accordance with the present in- 
vention as shown in Figs. 2 and 3, the digital data 35 
that is applied to the encoder 33 is encoded in the 
shapes of the glyphs 36 which the encoder 33 causes 
the printer 26 to print on the recording medium. These 
glyphs form a self-clocking glyph code because the 
code that is printed on the recording medium has a sep- 
arate glyph 36 for each of the encoded data values. In 
practice, as shown in Fig. 3B, each of the printed glyphs 
36 is defined by the pixel pattern that is printed within a 
generally rectangular, two dimensional, array 37 of pixel 
positions (referred to hereinafter as a "glyph celP or as 
a "data cell "). See Fig. 3B for an example. These glyph 
defining data cells 37 typically are tiled onto the record- 
ing medium in accordance with a predetermined spatial 
formatting rule which causes the glyph encodings 36 for 
successive data values to be spatially distributed in ac- 
cordance with a predefined template or pattern. For in- 
stance, the data cells 37 containing the glyph encodings 
36 for successive data values suitably are printed on the 
recording medium in accordance with a regular and re- 
peating logical data block formatting rule, such that the 
printed data cells are spatially organized in a two dimen- 
sional array of logical blocks of predetermined size, 
such as a 16 cell x 16 cell logical block format. 

Glyph shape encoding clearly permits of many dif- 
ferent implementations, some of which are suitable for 
the encoding of single bit digital values and others of 
which are suitable for the encoding of multi-bit values 
For example, single bit values ( n 1 " and tt 0 u ) conveniently 
are encoded by printing elongated, multi-pixel glyphs, 
each of which is composed of a predetermined number 
of adjacent "ON" (say, black) pixels which align along 
an axis that is inclined at an angle of about + 45° or -45° 
from the transverse axis of the recording medium de- 
pending on whether the data value encoded therein is 
a "1" or a "0". Such glyphs are examples of so-called 
"rotationally variant" glyphs because they can be 
mapped onto each other merely by rotational opera- 
tions. They also are examples of glyphs which are read- 
ily discriminate, even in the presence of significant dis- 
tortion and image degradation, because they do not 
tend to degrade into a common shape. 

An important advantage of selecting the glyphs 36 
so that they all have the same number of "ON" pixels is 
that the printed glyph code will have a generally uniform 



texture, which will take the form of a gray scale appear- 
ance when higher density glyphs are viewed by a casual 
observer. It, therefore, is worth noting that this advan- 
tage may be realized by encoding the data in the rotation 

5 and/or the contour (collectively referred to herein as the 
"shape") of the glyphs 36. For instance, single bit digital 
values may be encoded by rotationally invariant glyphs 
which have distinctly different contours, but the same 
number of "ON" pixels for the encoding of the "Vs" and 

10 "OV, respectively. See Fig. 3A for an example. The gray 
tone appearance of the printed glyph code can be 
"tuned" to an aesthetically pleasing gray tone by in- 
creasing or decreasing the ON pixel content of the 
glyphs. 

15 While glyph shape encoding can be extended in 
theory to the encoding of digital values of any given bit 
length, n, simply by utilizing a code having 2 n permissi- 
ble glyph shapes, the code should be selected with care 
to ensure that its glyph shapes can be discriminated 

20 from each other reliably because such discrimination is 
essential for accurately recovering the data that is en- 
coded therein. 

C. Decoding of Glyph Shape Codes 

25 

1. Overview 

Turning now to Fig. 4, printed glyph codes of the 
foregoing type are susceptible to being decoded by 
30 processing bitmap images of them. As will be seen, the 
image processing techniques that are provided for de- 
coding such glyph codes can tolerate a significant 
amount of image distortion and degradation, so codes 
carried by scanned-in photocopies and facsimile copies 
35 can be decoded, provided that the scanned-in docu- 
ment is not too many generations removed from the 
original. Of course, printed glyph codes can be regen- 
erated by employing a suitable electronic document 
processing system for decoding the code to recover the 
40 encoded data and by then reprinting the code with that 
very same data encoded therein, with both the decoding 
and re-encoding being performed essentially as de- 
scribed herein. 

In certain decoders, the image processing which is 
45 performed for decoding the glyph codes first locates the 
glyphs n the X-Y coordinates of the bitmap image space, 
then constructs a table for indexing the glyphs in the 
spatial order in which data was encoded n them, and 
then analyzes the glypins in indexed order for sequen- 
ce tially extracting the data values that are encoded in 
them. In other decoder, the image processing classifies 
the glyphs by their shapes while concurrently locating 
their centers in the bitmap image space, so the decoded 
values of the glyphs conveniently are indexed to the bit- 
55 rnap image space. However, these spatially indexed de- 
coded data values may be sorted in accordance with the 
spatial template or pattern that governs their spatial or- 
dering if it is desired to restore their serial order in the 
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time domain. 

2. Decoding By Binary Image Processing 
a. Introduction 

In the decoding process illustrated by Fig. 4, the bit- 
map image of the glyph code is first processed morpho- 
logically and/or through the use of a pixel search tech- 
nique to isolate the approximate or apparent centers of 
the glyphs, as at 41 . Predetermined ones of these ap- 
parent glyph centers, such as the apparent centers of 
the corner glyphs, then are employed as reference 
points for computing at 42 appropriate skew and X and 
Y scaling correction factors to compensate for the skew 
errors and the X and Y scaling errors, respectively, 
which may have been introduced into the glyph code 
while it was being copied and/or scanned-in. As will be 
seen, these compensating factors are employed for 
computing vectors that enable a glyph center labelling 
process to jump from glyph center-to-glyph center (or, 
more precisely, to a likely location of the next glyph cent- 
er). Thus, a relatively localized pixel search process is 
sufficient for labelling the apparent center pixel of each 
glyph with its X-Y image space coordinates, as at 43. 
Spurious image noise effectively is rejected at this point 
because no labels are provided for the noise compo- 
nents of the image. 

As will be recalled, data typically is encoded into the 
glyphs in logical block-by-block, cell-by-cell order. For 
that reason, as indicated at 45, the X-Y coordinate labels 
for the glyphs typically are sorted in accordance with the 
spatial order of the data encoding, thereby constructing 
an index table for serially addressing the glyphs in the 
same order as the data was encoded into them. Or, if 
desired, a pointer (not shown) may be provided for ran- 
domly accessing the glyphs at one or more preselected 
locations within the bitmap image space, such that an 
index is constructed at 45 for decoding selected ones of 
the glyphs in the order in which they are accessed. For 
example, a straightforward X-Y seek may be employed 
for relatively rapidly shifting such a pointer from the cent- 
er of any one glyph to the center of any other glyph in 
the bitmap image space by computing the direction and 
the number of glyph centers in and by which, respec- 
tively the X and the Y coordinates of any two given glyph 
centers are displaced from each other in the bitmap im- 
age space. Given that directional information and those 
intermediate glyph center counts, an appropriate seek 
may be executed by first incrementally shifting the point- 
er from glyph center-to-glyph center in the indicated di- 
rection along, say, the X-axis, until the pointer has 
skipped across the given number of intermediate glyph 
centers, and by then repeating the above process to in- 
crementally shift the pointer to its intended destination 
along the other or Y-axis. 

For recovering the encoded data values from the 
glyph code, 2" copies of the bitmap image of the code 
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(where n is the bit length of the data value encoded in 
each of the glyph shapes) are each filtered, as at 51 , by 
a filter that is matched to a respective one of the 2" per- 
missible glyph shapes. For example, each of these im- 
£ ages can be morphologically processed in accordance 
with a hit-miss filter that is weakly matched to a respec- 
tive one (and only one) of the permissible glyph shapes. 
This yields 2 n differently filtered versions of the bitmap 
image. Specifically, as a result of the hit-miss filtering, 
10 the pixel pattern proximate to any given glyph center or 
"data label" location in any given one of the filtered im- 
ages is dependent upon the precision of the match be- 
tween the hit-miss filter used to prepare the given image 
and the glyph residing at the given data label location 
15 (i.e., the closer the match, the greater the number of 
"ON" pixels proximate the data label location). There- 
fore, the pixel patterns of the filtered images are com- 
pared, as at 52, data label location-by-data label loca- 
tion in logical encoding order (or random access order), 
20 to determine and sequentially read out, as at 53, the da- 
ta values encoded in successive ones of the glyphs. 

b. Definitions 

25 Prior to considering the decoding process in further 
detail, it may be helpful to briefly define some of the 
terms that have been adopted for describing "morpho- 
logical image processing operations": 

30 "Morphological operation" is an operation on a bit- 
map image (called the "source image") that uses a 
local rule at each pixel location with the source im- 
age to create another bitmap image (known as the 
"destination image"). For convenience, the source 
35 and destination images sometimes are referred to 
as "pixelmap" images so that the operational rate 
can be viewed as operating on each "pixel". "Bit- 
map" and "pixelmap" are synonymous terms for a 
data structure of a certain type, and "bit" and "pixel 
40 " are used interchangeably herein to describe the 
contents of such a data structure. 
"Structuring Element (SE) is an image object, typi- 
cally of relatively small size and simple shape, for 
probing the source image to extract information 
45 from it through the use of a selected morphological 
operations. The SE's referred to herein below are 
binary SE's. They are illustrated by using solid cir- 
cles to identify their "ON" pixels and hollow circles 
to identify their "OFF" pixels. Their centers are iden- 
50 tified by a video cross. SE's also may include "Don't 
Care" pixels, so it is noted that such pixels are rep- 
resented by empty squares 

The following terms are specific to binary morpho- 
logical operations: 
55 "EROSION" is an operation that is performed by 
probing a binary source image with a SE to write an 
"on" (1) or an "off" (0) pixel into the destination im- 
age for each pixel location within the source image, 



EP 0 469 864 B1 



15 



35 



40 



45 



50 



6 



11 

with the logic level of the pixel that is written at any 
given location depending upon whether the SE is 
matched or not by the source image when it is cen- 
tered on the given pixel location. When the SE to 
be matched contains both "hits" and "misses/ the 
matching operation commonly is called a "hit-miss 
transform." However, to simplify this disclosure, the 
definition of EROSION has been expanded to in- 
clude such hit-miss transforms. 
"DILATION" is an operation that is performed by 
probing a binary source image with a SE to write 
the SE into the destination image on centers corre- 
sponding to the locations of all "ON" pixels in the 
source image. As used herein, the DILATION is de- 
fined only for "hits" in the SE, so "misses" are ig- 
nored. Thus, the dilated destination image is the un- 
ion of all replicas of the SE translated to all 1 -pixels 
of the source image. 

"OPENING" is an operation for replicating a SE in 
the destination image for each match to the SE in 
the source image. It is equivalent to an EROSION 
of a source image by an SE followed by a Dl LATION 
of the eroded image by the same SE. In keeping 
with the foregoing definitions of EROSION and DI- 
LATION, the definition of the OPENING operation 
has been expanded to include an EROSION with 
an SE containing both "hits" and "misses" followed 
by a DILATION with only the "hits" in the SE. 
"CLOSING" is an operation composed of a DILA- 
TION of a source image followed by an EROSION 
of the dilated image. A CLOSING of an image is 
equivalent to a bit inversion of an OPENING that is 
performed on a bit inverted source image. In view 
of the foregoing definition of DILATION, it will be un- 
derstood that a CLOSING is defined herein only for 
"hits" in the SE, so any "misses" are ignored. 

Morphological operations are translationally invari- 
ant. In other words, a source image may be translated 
prior to be transformed, thereby causing the result to be 
translated or shifted by the same amount, without oth- 
erwise changing it. This means that these operations 
may be implemented with a high degree of parallelism 
because each bit or pixel in the source image is proc- 
essed in accordance with the same rule. 

EROSION, DILATION, OPENING and CLOSING 
operations performed with SE's consisting only of "hits" 
are geometrically "increasing" operations. Therefore, if 
a first image is contained in a second image, any of 
these operations that are performed with such a SE on 
the first image will also be contained in the second im- 
age. Furthermore, CLOSING is "extensive", and OPEN- 
ING is "antiextensive". Accordingly, the source image is 
contained in the destination image when the source is 
transformed by a CLOSING, and the destination image 
is contained in the source image when the source is 
transformed by an OPENING. The result of OPENING 
and CLOSING operations are independent of the posi- 
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tion of the center of the SE. Moreover, OPENING and 
CLOSING operations are indempotent, which means 
they will not change the transformed image if they are 
reapplied to it. 

5 Other terms that are sometimes used in describing 

morphological operations are: 

a "4-connected region" is a set of ON ("1")pixels, 
such that a path between any two of those pixels 
10 can be found that stays entirely within the set of ON 
pixels and consists of only horizontal or vertical 
1 -pixel moves. 

a "8-connected region" is a set of ON ("1 ")pixels, 
such that a path between any two of those pixels 
15 can be found that stays entirely within the set of ON 
pixels and consists of only horizontal, vertical or di- 
agonal 1 -pixel moves. 

A "hit-miss" SE is an SE that specifies a non-zero 
set of ON pixels and a non-zero set of OFF ("0") 
20 pixels, with those two sets being non-overlapping 
(i. e., non-intersecting). A "weakly" matched filter 
specifies relatively few pixels of the pixel pattern to 
which it is matched, while a "strongly" matched filter 
specifies a large percentage of the pixel pattern to 
25 which it is matched. 

A "hit-only" SE is an SE that specifies a non-zero 
set of ON pixels. 

c. A Detailed Implementation 

30 

Referring now to Fig. 5, in keeping with generally 
accepted practices, the processor and main memory re- 
sources which are utilized to execute the glyph decoding 
program are reinitialized, as at 61 , each time the decod- 
es jng program is invoked. In the embodiment illustrated in 
Fig. 1, the processor 22 communicates with its main 
memory 23 and, if necessary, its mass memory 24 (Fig. 
1 ) to carry out the glyph decoding process, but it will be 
evident that the decoding process could be performed 
40 under the control of a separate programmed processor 
(not shown) through the use of the main memory 23 or 
through the use of a separate memory system (not 
shown). 



Once the system has been initialized to decode a 
given glyph code, a copy of the bitmap image of the code 
is loaded into main memory, as at 62, and this image 
so then is transformed, as at 63, to provide an identically 
scaled bitmap image composed of at least one centrally 

located bit or "p ixe, » n but no more tnan a few > for eacn 
of the glyphs of the code. As described hereinbelow, the 
process for performing the transformation 63 typically is 
55 tailored to the spatial density at which the glyphs are 
printed because high density glyphs are more likely to 
be inseparably merged by the blurring that occurs during 
printing, copying and scanning than lower density 
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glyphs. If the scanned-in glyphs are well separated, they 
may be shrunk to a single pixel near their respective 
centers if, on the other hand, the scanned-in glyphs are 
touching, they may first be isolated from each other by 
filterirng and then shrunk. For the moment it will be as- 
sumed that the transformation 63 transforms the 
scanned-in bitmap of the glyph code to a bitmap con- 
taining a single pixel at the approximate center of each 
data cell of the code, but it is to be understood that this 
is not essential. 

ii. Determining Skew and Scale 

In practice, the scanned-in image of the glyph code 
which is to be decoded may be skewed from the hori- 
zontal in a clockwise or counterclockwise direction, and 
may be distorted by scaling errors of different magnitude 
along its X-axis and/or its Y-axis. For that reason, pro- 
vision is made at 65 for computing skew and scale cor- 
rection factors to correct for such errors on a glyph-by- 
glyph basis (as shown) or on a data block-by -data block 
basis not shown or through the use of an image deskew- 
ing and rescaling process (also not shown). 

As will be evident, skew and scale correction factors 
can be computed from the X-Y coordinates, in the 
scanned-in bitmap image space, of any three or more 
non-colinear reference points that have a nominal (i.e., 
error-free) spatial relationship which is known or capa- 
ble of being determined. One of these reference points 
is selected to define a translationally invariant reference 
position, so that the skew and the scaling errors can be 
determined by comparing the distance and angle at 
which the actual and nominal positions of each of the 
other reference points are displaced from that spatially 
fixed reference position. 

As previously pointed out, the data encoded glyphs 
typically are printed at a predetermined spatial density 
in generally square data arrays or blocks, so the centers 
of the glyph defining data cells (commonly referred to 
herein as the glyph centers) usually are arranged in a 
generally rectangular configuration. Therefore, the 
skew and scale correction factors suitably are computed 
from the X-Y bitmap image space coordinates of the ap- 
parent center pixels of at least three of the corner glyphs 
of the printed glyph code (although, it will be apparent 
from the foregoing description of the characteristics re- 
quired of the so-called "reference points" that the appar- 
ent centers of any other uniquely identifiable glyphs 
could be employed in lieu of or in addition to the appar- 
ent centers of the corner glyphs). Thus, as illustrated, 
the X-Y coordinates of one after another of the selected 
corner pixels are identified at 66 and stored at 67, until 
it is determined at 68 that all of the information that is 
needed to compute the skew and scale correction fac- 
tors at 65 has been collected. 

Again, however, is to be understood that the appar- 
ent centers of any other uniquely identifiable glyphs 
could be employed, in lieu of or in addition to the appar- 



ent centers of the corner glyphs, for computing such 
skew and scale correction factors, so reference is made 
to the foregoing description of the characteristics re- 
quired of the so-called "reference points." Moreover, it 
5 is to be understood that the center pixels of the corner 
glyphs may be used for computing the skew and scale 
correction factors for other types of glyph code patterns, 
such as inexagonal lattice patterns. 

Relatively straightforward image analysis can be 
io performed on the transformed bitmap that is provided 
by the transformation step 63 for identifying the X-Y co- 
ordinates of the corner pixels with sufficient precision to 
compute appropriate skew and scale correction factors. 
If the bitmap image of the apparent glyph center pixels 
'5 is scanned in left -to-right and top-to-bottom order, start- 
ing slightly above the bitmap image, the first ON pixel 
that is encountered may be either the upper left-hand 
(UL) corner pixel or a pixel at or near the upper right- 
hand (UR) corner of the image. To resolve this ambigu- 
20 jty, this pixel is tentatively accepted as being the UL cor- 
ner pixel, but it is subject to being deaccepted in favor 
of applying the UL corner pixel designation to any sub- 
sequently scanned pixel which is more than M pixels to 
the left and no more than N scan lines below the tenta- 
25 tively accepted pixel. 

In some situations, the UL corner glyph may be 
missing, so the pixel representing the approximate cent- 
er of the second glyph in the first line of the glyph code 
may be tentatively identified as being the UL corner pix- 
30 el. If, however, N is chosen to be slightly greater (in scan 
lines) than the average center-to-center vertical spacing 
of the glyph or data cells, this error can be detected and 
corrected by imputing a UL corner pixel location to the 
bitmap image if an ON pixel is encountered anytime dur- 
35 ing the scanning of the N scan lines at a distance of 
roughly one data call to the left of the tentatively accept- 
ed pixel. In other situations, the pixel marking the ap- 
proximate center of the first glyph in the second row of 
data may be slightly to the left of the UL corner pixel. If, 
40 however, M is selected to be a suitably large fraction 
(say, about one-half) of the average horizontal center- 
to-center horizontal displacement (in printer pixels or 
pels) of the data cells, this anomaly generally will be ig- 
nored if the bitmap image is skewed by no more than 
45 20° or so. In short, the preferred values for M and N de- 
pend on the data cell size in pels of the printed glyphs. 
For a 1 0 pel x 1 0 pel data cell size, M suitably is selected 
to be about 5 pixels and N suitably is selected to be 
about 15 scan lines. By way of comparison, for a 5 pel 
50 x 5 pel cell size, M typically is selected to be about 3 
pixels and N typically is selected to be about 8 scan 
lines. 

The above-described process for locating the UL 
corner of a scanned-in glyph code pattern is extensible 
55 by straightforward analogy to provide corresponding 
processes for locating the apparent center pixels of the 
upper right-hand (UR) corner, the lower left-hand (LL) 
corner, and the lower right-hand (LR) corner glyphs of 
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the scanned-in code pattern. The X-Y coordinates of 
these corner pixels can be identified in the bitmap image 
space by assigning (0,0) reference coordinates to, say, 
the pixel at the UL comer and by then referencing the 
coordinates of all of the other corner pixels to those ref- 
erence coordinates. 

Alternatively, the apparent center pixel of any or all 
of the corner glyphs can be found by performing one or 
more scans along a scan line that is sloped upwardly to 
the right for the UL and LR corner and upwardly to the 
left for the URand LL. This scan line is initially positioned 
a safe distance outside the glyph code pattern, but it is 
incrementally shifted in toward the targeted corner glyph 
for each successive scan to progressively close in on it. 
Therefore, the apparent center pixel of the targeted cor- 
ner glyph ordinarily is the first "ON" pixel that this scan 
process encounters. 

Given the data cell size (in printer pels) of the print- 
ed glyphs and the X-Y bitmap image space coordinates 
of the apparent center pixels of the printed glyph code 
pattern, the rotation and scaling of the bitmap image of 
the glyph code can be determined as described above. 
Alternatively, the periodicity of the glyphs can be deter- 
mined by performing a frequency transform, such as a 
Fourier transform or a Walsh transform, on either the 
scanned-in bitmap of the glyph code or on the bitmap of 
the glyph center pixels. 

iii. Jump, Search, and Label 

Thus, it will be evident that the average number of 
pixels between the centers of adjacent glyphs in the bit- 
map image of the glyph code also can be computed, as 
at 80. Given that information, a jump and search process 
can be initiated at, say, the UL corner pixel of the bitmap 
image of the apparent glyph centers to serially identify, 
as at 71, and store, as at 72, approximate X-Y bitmap 
image space coordinates for the apparent centers of 
one after another of the spatially adjacent glyphs from 
one after another of the spatially adjacent rows of the 
printed glyph code. This coordinate labeling process 
starts with a jump from the UL corner pixel to the expect- 
ed location of the center of its right-hand neighbor. If an 
ON pixel is found at that location, the pixel is labeled 
with its X-Y coordinates, and the process then jumps to 
the expected center location of the next neighboring 
glyph. If, on the other hand, the process fails to find an 
ON pixel at the expected center location, it carries out 
an expanding search, typically using an expanding dia- 
mond-like or spiral-like search pattern, to determine 
whether there is an ON pixel within a few pixel positions 
in one direction or another of the expected center loca- 
tion. If so, the process labels the first "ON" pixel it en- 
counters with its X-Y coordinates, and then jumps to the 
likely center location of the next neighboring glyph. Con- 
versely, if the search fails to find a nearby ON pixel, the 
process suitably returns to the location at which it ex- 
pected to find the center pixel for the glyph to label that 



location with its X -Y coordinates before jumping ahead 
to locate the center pixel of the next glyph. This process 
continues glyph-by-glyph and row-by-row of the 
scanned-in glyph code to provide a X-Y coordinate label 
s in the bitmap image space for each and every glyph 
center location. 

iv. Recalibrated Glyph Center Labeling (Optional) 

As shown in Fig. 6, the glyph center labeling that is 
performed by the above-described jump and search 
process may contain errors if the glyph centers are not 
well separated in glyph center bitmap image Some of 
the transformation processes that may be the employed 
for producing a glyph center bitmap image from a 
scanned-in bitmap image of a high density glyph code 
do not guarantee that such a separation will exist for all 
glyph centers, so there is an optional calibration process 
for recomputing the X-Y coordinate labels for the glyph 
centers of such images. 

Returning to Fig. 5, it will be seen that this optional 
calibration process uses the X-Y coordinates for the 
center of gravity of one or more sets of glyph center pix- 
els for recomputing the X-Y coordinates for all of the 
glyph center pixels within each of those sets based on 
the average distance of those pixels from the center of 
gravity of the given set. This calibration may be per- 
formed once to calibrate the X-Y coordinates of the 
glyph center pixels relative to the center of gravity of the 
glyph center bitmap image. Or, as shown, it may be re- 
peated, as at 81 , for calibrating the X-Y coordinates of 
successive sets (e.g., 16x16 blocks) of glyph center 
pixels, as at 82, with respect to their respective centers 
of gravity, as determined at 83. 

v. Restoring Encoded Data Values to the Time 
Domain 

After the X-Y coordinate labels have been applied 
to the glyph center pixels and all necessary calibrations 
of them have been completed, the X-Y coordinate labels 
ordinarily are sorted into a logical block sequence, 
thereby serially re-ordering them in accordance with the 
order in which data is encoded into the glyphs labeled 
by them. Moreover, as indicated at 85, incrementally in- 
creasing index values are assigned to the re-ordered la- 
bels so that they can be retrieved easily in sorted se- 
quence. 

vi. Determining Data Values from Glyph Shapes 

Turning to Fig.7, given the indexed X-Y coordinate 
labels for the glyphs, the glyph code can be decoded by 
analyzing the shapes of the individual glyphs in logical 
sequence to serially determine the data values that have 
been encoded in them. To perform this glyph shape 
analysis, the scanned-in bitmap image of the glyph 
code, as at 101, is separately filtered at 102 in accord- 
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ance with a plurality of different filters, as at 1 03, each 
of which is selected to pass pixels from a respective one 
of the permissible glyph shapes and to suppress pixels 
from all of the other glyph shapes. For that reason, the 
filters may be described as being individually "tuned" to 
respective ones of the permissible glyph shapes. The 
bitmap filtering may be performed in series as shown in 
Fig. 7 or in parallel as indicated in Fig. 4. In any event, 
the filtered bitmaps are stored at 104, so that they can 
be retrieved during the glyph-by-glyph analysis phase 
of the decoding process as described below. 

To provide the filtered bitmap images, the bitmap 
image of the glyph code advantageously is morpholog- 
ically ERODED, through the use of independent opera- 
tions, in accordance with a plurality of different weak hit- 
miss filters, each of which is relativety well matched to 
a different one of the permissive glyph shapes and rel- 
atively poorly matched to all of the others. These filters 
are referred to as "weak" hit-miss filters because they 
only loosely specify the shapes of the glyphs (i. e., the 
patterns of "ON" and "OFF" pixels that define the glyph 
shapes). Consequently, the filtering of a matching glyph 
within the source image typically causes several ON pix- 
els to be written into the target or filtered image near the 
center of the matching glyph, while the filtering of a non- 
matching glyph results in significantly fewer, if any, ON 
pixels being written into the targeted image near the 
center of the non-matching glyph In other words, the fil- 
tering causes a significantly larger number of ON pixels 
to be written into a filtered image for the glyphs that are 
well matched by the filter that is used to produce that 
particular image than for the glyphs that are unmatched 
or only poorly matched by that filter. 

After it is determined at 105 that all of the filtered 
bitmap images have been constructed, a glyph index 
pointer 107 is set, as at 106, to the index value for the 
first glyph that is to be decoded, thereby retrieving the 
X-Y image space coordinate label for the first glyph from 
memory. This label is used at 111 for spatially address- 
ing one after another of the filtered bitmap images at 
approximately the center of the glyph that is to be de- 
coded, so that the ON pixels that each of those images 
contains proximate the center of that particular glyph 
can be counted as at 112. These counts, in turn, are 
stored in separate cells of a data array, as at 113. 

'Typically, the pixel counting is performed by starting 
at the labeled center point of the addressed glyph and 
by then moving outwardly from there to count the 
number of ON pixels falling within a selected number of 
progressively larger squares centered on the glyph 
center point. This "square ring" search pattern expands 
in all directions at a rate of one pixel position/ring, but 
the search is confined to the data cell for the glyph that 
is being decoded. For example, as shown in Fig. 8 a 
three ring search is appropriate for glyph codes written 
at a density of 900 bits/in 2 (about 1 .4 bits/mm 2 using 10 
pel x 10 pel data cells for the glyphs. In contrast, as 
shown in Fig. 9, a two ring search is preferred for glyph 
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codes written at a density of 3600 bits/in 2 (about 5.6 bits/ 
mm 2 ) using 5 pel x 5 pel data cells. In both cases, the 
innermost ring is the X-Y labeled center point of the 
glyph. 

5 Upon confirming at 115 (Fig. 7) that all of the pixel 
counts for the given glyph have been accumulated, the 
data array containing them is sorted at 1 1 6 in rank order 
by count value, so that the two largest counts can be 
extracted from it straightforwardly for comparison, as at 

10 117. If these counts are unequal, as determined at 1 21 , 
the data value associated with the glyph shape yielding 
the largest count is assigned to the index for the given 
glyph, as at 122. If, on the other hand, the equality test 
121 determines that the two largest counts are equal, 

15 an error count is incremented, as at 1 24, to track the 
number of decoding ambiguities that occur and the X-Y 
coordinate label of the ambiguous glyph is stored to in- 
dicate where the ambiguity or "error" occurred. There- 
after, an estimate of the data value that was encoded in 

20 the ambiguous glyph is assigned to its index, as at 125 
Then, if it is determined at 126 that there are more 
glyphs to De decoded, the glyph index value is incre- 
mented at 107 to repeat the count and compare process 
for the next glyph. 

25 

vii. Systems Utilizing Error Correction Encoding 

As shown in Fig. 10, glyph shape encoding and de- 
coding may be employed for data containing error cor- 
30 rection codes. To that end, the data is glyph shape en- 
coded at 131 , and the encoded glyph shapes then are 
converted into a raster format at 1 32 so that they can 
be printed at 1 33 on a suitable recording medium, such 
as plain paper, by a bitmap printer. Subsequently, the 
35 printed image (which may include human readable in- 
formation, as well as the glyph code) is converted into 
a bitmap image by an input scanning operation 1 34. This 
bitmap image is parsed at 1 35 to isolate the scanned-in 
image of the glyph code, so that the above-described 
40 decoding process can be employed at 1 36 to assign de- 
coded data values to the glyph or data indices. The 
glyph decoded data is then processed at 1 37 by an error 
correction code decoder to provide the original data in 
error corrected form. 

45 

viii. Transforms for Isolating Glyph Center Pixels 

Returning to the problem of identifying the centers 
of the glyphs in a glyph shape code, three different tech- 
so niques will be described for performing that function. 
Two methods for transforming the scanned-in bitmap 
image of the glyph code into a bitmap of the glyph center 
pixels, as at 63 in Fig. 5, will be described in this section, 
and a third method that does not require such a trans- 
55 formation will be described in the following section.. 
Therefore, in this section, it will be assumed that the 
transformation process 63 is carried out to isolate the 
glyph centers as a separate and distinct step from the 
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evaluation of the glyphs. As will be seen, the transfor- 
mation process 63 may be performed through the use 
of large filters representing the periodicity of the glyph 
code (these filters typically are on the order of 2-6 cycles 
long) or through the use of small filters representing in- s 
dividual glyph shapes (these filters usually are some- 
what smaller than the glyphs). 

Turning first to the large filter implementations of the 
transformation 63, it will be understood that the glyphs 
of lower density glyph codes (i.e., these that are printed 
with densities of up to about 2500 glyphs/in 2 (about 3.87 
glyphs/mm 2 ) using glyph cells as small as 6 pels x 6 
pels) usually are reasonably well separated in the 
scanned-in bitmap image of the glyph code. Therefore, 
as shown in Fig. 11, their apparent center pixels gener- 
ally can be identified with sufficient precision by OPEN- 
ING the scanned-in bitmap image 140 (see Fig. 12) in 
accordance with a large horizontal hit-miss filter, as at 
141, and a large vertical hit-miss filter, as at 142. The 
results of these OPENING operations are bit-ORed at 
1 43 to construct a first level filtered bitmap image having 
relatively little diagonal ON pixel structure. Next, the fil- 
tered bitmap image is OPENED at 144 and 145 in ac- 
cordance with the horizontal and the vertical hit-miss fil- 
ters, respectively, and the results of these operations 
are bit-ANDed, as at 146, to provide a second level fil- 
tered bitmap image having even less diagonal structure 
and less vertical and horizontal structure. See Fig 13. If 
it is desired to further reduce the ON pixel structure of 
the second level filtered image (see Fig 14) one or more 
additional iterations of the second level filtering process 
may be employed as shown in Fig. 15 at 151-156. 

As shown in Fig. 19, for locating the glyph center 
pixels of higher density glyphs (i.e., densities up to 3600 
glyphs/in 2 (about 5.6 glyphs/mm 2 ) using glyph cells as 
small as 5 pels x 5 pets),, the bitmap image of the glyph 
code suitably is OPENED at 161 and 162 in accordance 
with large horizontal and vertical hit-only filters, respec- 
tively, and the results of those processes are then bit- 
ANDed at 163 to construct a bitmap image composed 
of better separated marks. 

The bit-ANDing 163 of the image OPENING oper- 
ations 161 and 162 may create some unintended holes 
at glyph center locations in the resulting bitmap image, 
but these holes can be filled. To that end, this particular 
version of the transformation process 63 (Fig. 5) may 
further include one or more iterations of a fill and repair 
process. To carry out this fill and repair process, as 
shown in Fig. 20, the filtered bitmap is first DILATED at 
171 and 172 in accordance with large horizontal and 
vertical hit-only filters, respectively, and the dilated im- 
ages then are bit-ANDed at 1 73 to prevent the bitmap 
image from expanding. That image, in turn, is OPENED 
at 174 and 175 in accordance with either the large hit- 
only filter or the large hit-miss filter, and the results of 
the OPENING operations 1 74 and 1 75 then are bit-AN- 
Ded at 176. 

Upon the completion of the fill and repair process, 



20 

the bitmap image may have several ON pixels proxi- 
mate at least some glyph locations. However, the image 
can be thinned to approximately one pixel per glyph by 
performing an iterative thinning process on it until thin- 
ning stops. As shown in Fig. 22, this thinning process is 
initiated with a copy of the bitmap image that is to be 
thinned, as at 1 90, and with the first of a set of four hit- 
miss SE's, 191-194, respectively. These hit-miss filters 
1 91 -1 94 specify spatial sequences of two ON pixels and 
one OFF pixel at angles of 0°, 90°, 180°, and 270°, re- 
spectively. During the initial iteration of this thinning 
process, the bitmap first is ERODED, as at 195, in ac- 
cordance with the first SE 1 91 , and the ERODED bitmap 
then is XORed at 196 with the image 190 that is being 
thinned, whereby a single ON pixel is thinned or 
"trimmed" from each glyph location that contains a plu- 
rality of ON pixels at the orientation of the SE 191 , with 
the pixel that is trimmed being the one that aligns with 
the center position of the SE 191. Following this initial 
thinning, an SE index 197 is incremented to repeat the 
ERODE and XOR steps 1 95 and 1 96 on the thinned im- 
age, using one after another of the remaining structuring 
elements 192-194, so that excess ON pixels are 
trimmed in a predetermined side-to-side order from all 
horizontally and/or vertically adjacent sets of ON pixels. 

After each iteration of the thinning process, as de- 
termined at 198, the thinned bitmap image is bit-com- 
pared at 1 99 with the bitmap image 1 90. If the images 
are identical, thinning has stopped, so the process is 
completed. Otherwise, the thinned image is copied at 
190, and the process is then repeated in an attempt to 
further thin the image. 

Even higher density glyph codes having spacial 
densities up to, say, 5625 glyphs/in 2 (about 8.72 glyphs/ 
mm 2 ) with glyph cells as, say, small as 4pels x 4pels 
may be transformed to locate the apparent centers of 
their glyphs using essentially the same process as de- 
scribed above for the transformation of the medium den- 
sity codes. However, the transformation of those higher 
density codes generally requires several iterations of 
the fill and repair process 171-176 (Fig. 20). 

Alternatively, as pointed out above, the transforma- 
tion process 63 (Fig. 5) can be performed through the 
use of small, hit-miss filters that are weakly matched to 
the permissible glyph shapes. To accomplish that, as 
shown in Fig. 23, the bitmap image of the glyph code is 
ERODED, as at 201 and 202, in accordance with small 
SE's that are weakly matched to respective ones of the 
permissible glyph shapes, and the results of these ERO- 
SIONS then are bit-ORed, as at 203, to construct a fil- 
tered bitmap image composed of smaller marks or pixel 
patterns. For example, when rotationally variant glyphs 
are employed, the bit-ORing 203 of the results of the 
EROSIONS 201 and 202 will produce a filtered bitmap 
composed of smaller, more circular bit or pixel patterns 
See Fig. 1 6. This filtered bitmap generally contains sev- 
eral pixels near the center of each glyph. 

Accordingly, a thinning process of the above-de- 
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scribed type (See Fig. 22) usually is needed for thinning 
the filtered bitmap to approximately one ON pixel per 
glyph. This thinning process may be preceded by a 
bounding box expansion of the pixel patterns at the 
glyph locations to enable the thinning to more precisely 
isolate the centermost ON pixel of each glyph. See Fig. 
17 for an example of a bitmap image produced by such 
a bounding box expansion. 

The thinning of the filtered bitmap (Fig. 16) or of its 
bounding box expanded counterpart may stop before all 
of the glyph centers are well defined by a single, isolated 
ON pixel. In the case of higher spatial density codes, 
this may cause potentially significant labelling errors to 
occur during the jump, search and label process 71-73 
(Fig. 5), but the optional calibration process 81 -83 (Fig. 
5) usually is able to recalibrate the glyph center labels 
with sufficient precision for enabling the glyph shape 
evaluation phase of the decoding process to track from 
glyph-to-glyph, as at 107 in Fig. 7, 

3. Decoding By Convolution Filtering 

Turning now to Fig. 24, there is a convolution filter- 
ing process for decoding the glyphs of a glyph shape 
code from a bitmap image of the code, as at 21 1 . As will 
be seen, this process can be carried out, without having 
to shrink the glyphs to locate their apparent center pixels 
in the X-Y image. Instead, the bitmap image 211 is sep- 
arately convolved at 212 with n different filters, each of 
which is strongly matched to a corresponding one of the 
n permissible glyph shapes. The images produced by 
these convolutions, in turn, are processed glyph-by- 
glyph, as at 21 3-218, for identifying their X_Y coordinate 
locations in the bitmap image space while essentially 
concurrently classifying them by their shapes for decod- 
ing, as at 221 -224. Alternatively, the bitmap image could 
be convolved, data cell-by-data cell, with a set of n 
matched filters. Furthermore, it will be understood that 
multiple convolutions could be performed for each per- 
missible glyph shape to furnish an extended set of con- 
volved images for providing additional discrimination 
between the different glyph shapes. 

As shown in Figs 25A and 25B, the convolution fil- 
ters may be unweighted or weighted, as at 228 and 229, 
respectively. An unweighted filter is composed of binary 
positive and negative values, while a weighted filter is 
composed of positive and/or negative gray-scale val- 
ues. If weighted filters, such as the filter 229, are used, 
they advantageously are weighted to emphasize the 
more distinctive features of the glyph shapes to which 
they are matched and to deemphasize the more distinc- 
tive features of the other glyph shapes. 

More particularly, for decoding a glyph code in ac- 
cordance with the process shown in Fig. 24, three or 
more non-colinear reference points of known nominal 
spatial relationship to one another are located in the 
glyph code bitmap image space, as at 231 , for comput- 
ing bitmap skew and X and Y scale correction factors, 
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as at 232. The X and Y scale correction factors are em- 
ployed at 233 for calibrating the average center-to-cent- 
er displacement of the glyphs along the X-axis and the 
Y-axis, respectively, of the bitmap image space. The dis- 
s placement values upon which those calibrations are 
performed may be computed either from prior knowl- 
edge of the spatial density (in printer pels) at which the 
glyphs were printed or from the spatial periodicity of the 
bitmap image of the glyph code as determined by a fre- 
quency transform, such as a fast Fourier transform or a 
fast Walsh transform. The skew correction factor, on the 
other hand, is utilized at 21 3 for setting the angles of the 
X and Y displacement vectors that enable the image 
processing to jump from one glyph position to the likely 
position of the next glyph in the bitmap image space with 
sufficient precision to enable the center of the next glyph 
to be located by performing a search over a relatively 
small local area. This local search suitably is carried out 
in accordance with an expanding diamond-like or an ex- 
panding square ring-type search pattern. In short, it will 
be apparent that there are substantial similarities be- 
tween the preliminary phases of this and the above-de- 
scribed decoding processes. However, it also will be ev- 
ident that this process requires substantially less pre- 
liminary processing of the glyph code bitmap image than 
those binary decoding processes. 

The glyph code is decoded glyph-by-glyph, starting 
at 21 3 approximately at the center of, say, the UL corner 
glyph (suitable processes already have been described 
for locating that center). To perform the decoding, the 
bitmap image is convolved at 212 with each of the n 
glyph matching filters. This produces n gray-scale im- 
ages, each of which represents the convolved response 
of the glyph code image to a filter that is relatively strong- 
ly matched to a respective one of the n permissible glyph 
shapes. A local search is conducted at 214 in each of 
these convolved images, from the approximate or esti- 
mated location of the glyph that is being decoded, to la- 
bel the maximum convolution values the respective im- 
ages contain for that particular glyph with their X-Y im- 
age space coordinates, as, at 215. As shown in Fig. 24, 
these local maximum convolution values are readout 
from the convolved images at 214 and are indexed by 
their X-Y bitmap image space coordinates at 215, but it 
will be seen that the X-Y coordinates of the local maxima 
may be used in an alternative embodiment for indexing 
the sums of the convolution values from a small area 
surrounding those local maxima. 

The indexed convolution values (i. e., local maxima 
or sums) for the n convolved images are sorted in rank 
order by value at 216, and the two highest values then 
are compared at 217. If the values are unequal, as de- 
termined at 221 f the data value for the glyph that is being 
processed is decoded by reference to the convolution 
producing the greater value and the X-Y label for that 
convolution value is assigned to the decoded data value 
for indexing it in the bitmap image space. See 222. On 
the other hand, if it is determined at 221 that the two 
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largest convolution values are equal, the X-Y label for a 
selected one of them is recorded to identify an error lo- 
cation and an error count is incremented, as at 223. 
Thereafter, as indicated at 224, an estimated decoded 
data value is provided by reference to the convolution 
producing the selected convolution value, and the X-Y 
label or index for the selected convolution value is as- 
signed to the decoded data value for indexing it in the 
bitmap image space. 

The foregoing process is repeated to decode the 
next glyph if it is determined at 21 8 that there is another 
glyph to be decoded. Whenever there is another glyph 
to be decoded, the decoding process employs the bit- 
map image space X-Y coordinates (i. e., index location) 
of a previously decoded neighboring glyph for advanc- 
ing to the next glyph through the use of the above-de- 
scribed jump and search routine. 

Referring to Fig. 26, to increase the noise immunity 
of this decoding process, each of the local maximum 
convolution values for the glyph that is being decoded 
may be summed at 231 with its near neighboring con- 
volution values from a small surrounding area For ex- 
ample, the convolution values may be accumulated, im- 
age-by-image, from a small diamond or square shaped 
area centered on the local maximum for the glyph that 
is being analyzed in each of the convolved images. The 
X-Y locations of these local maxima, as determined at 
233, then are employed for labelling the sums of the con- 
volution values accumulated from the respective imag- 
es, as at 234, and the sums then are sorted in rank order 
by value at 235. From that point on, the decoding proc- 
ess essentially is the same as the previously described 
version of this type of decoding. 

Conclusion 

In view of the foregoing, it will now be understood 
that the present invention provides self-clocking glyph 
shape codes, including codes that have a pleasing print- 
ed appearances and substantial tolerance to image 
degradation and distorsion. It also will be apparent that 
such codes can be regenerated as desired. Further- 
more, it will be evident that such codes can be decoded 
using a variety of different decoding techniques, includ- 
ing decoding processes that adaptively scale them- 
selves for the decoding of spatially periodic codes of dif- 
ferent spatial periodicities. 



Claims 

1. A method of storing digital values of predetermined 
bit length, n, in machine readable format on a hard- 
copy recording medium, comprising the steps of: 

encoding said digital values in a corresponding 
one of 2 n distinctive, rotationally variant or in- 
variant, discrimminable glyph shapes each 
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glyph shape being composed of substantially 
the same number of ON pixels to generate a 
set of glyph shapes that vary in accordance with 
said digital values, and 
s writing said set of glyph shapes on said record- 

ing medium in a predetermined logical order 
and in accordance with a predetermined spa- 
tially distributed pattern for storing said digital 
values in a self-clocking code. 

10 

2. The method of Claim 1 wherein at least some of said 
shapes are rotationally variant. 

3. The method of Claim 2 wherein 
is said glyphs are elongated along axes that are 

tilted at angles of plus and minus 45° with respect 
to a horizontal axis to discriminate at least some of 
said digital values from each other. 

20 4. The method of any one of Claims 1 to 3 wherein 

said glyphs are composed of respective pixel 
patterns that are printed in said region in tiled, 
two dimensional data cells of predetermined 
25 size, and 

said pixel patterns include substantially identi- 
cal numbers of ON pixels and OFF pixels, such 
that the marked region of said recording medi- 
um has a generally uniform textured appear- 
30 ance. 

5. The method of Claim 4 wherein 

said data values are single bit binary values, 
35 and 

said glyph shapes are elongated along axes 
that are tilted at angles of plus and minus 45° 
with respect to a horizontal axis depending on 
the values encoded therein. 

40 

6. A self-clocking code for encoding digital values of 
predetermined bit length, n; said code comprising 

glyphs conforming to selected ones of 2 n dis- 
45 tinctive, rotationally variant or invariant, dis- 

crimminable glyph shapes each glyph shape 
being composed of substantially the same 
number of ON pixels; 

said digital values being encoded in the shapes 
so of said glyphs, said glyph shapes being pre- 

sented in a logical order and in accordance with 
a predetermined spatially distributed pattern. 

7. A process for regenerating a printed self-clocking 
55 glyph shape code which has been encoded in ac- 
cordance with any of Claims 1 to 5, comprising the 
steps of: 
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decoding the printed code for recovering the 
digital values encoded in said glyph shapes; 
re-encoding said digital values in re-generated 
glyph shapes and printing said re-generated 
glyph shapes on a recording medium in accord- 
ance with the method of any of claims 1 to 5 . 

A hardcopy record for inputting machine readable 
information into an electronic document processing 
system, comprising: 

a hardcopy recording medium; and 

a self-clocking code of claim 6 written on said 

recording medium. 



Patentanspruche 

1. Verfahren zum Speichern von digitalen Werten mit 
einer vorbestimmten Bitlange n in einem maschi- 
nenlesbaren Format auf einem Hardcopy-Aufzeich- 
nungsmedium, wobei das Verfahren folgende 
Schritte umfaGt: 

Codieren der digitalen Werte in einer entspre- 
chenden von 2 n distinktiven, bezuglich der Ro- 
tation variierenden Oder nicht variierenden, un- 
terscheidbaren Glyphenformen, wobei sich je- 
de Glyphenform im wesentlichen aus einer glei- 
chen Anzahl von ON-Pixeln zusammensetzt, 
urn einen Satz von in Ubereinstimmung mit den 
digitalen Werten variierenden Glyphenformen 
zu erzeugen, und 

Schreiben des Satzes von Glyphenformen auf 
das Aufzeichnungsmedium in einer vorbe- 
stimmten logischen Reihenfolge und in Uber- 
einstimmung mit einem vorbestimmten raum- 
lich verteilten Muster, um die digitalen Werte in 
einem selbsttaktenden Code zu speichern. 

2. Verfahren nach Anspruch 1, wobei wenigstens ei- 
nige der Formen bezuglich der Rotation nicht vari- 
ieren. 

3. Verfahren nach Anspruch 2, wobei 

sich die Glyphen entlang von Achsen erstrek- 
ken, die mit Winkeln von plus oder minus 45° ge- 
genuber der horizontalen Achse geneigt sind, um 
wenigstens einige der digitalen Werte voneinander 
zu unterscheiden. 

4. Verfahren nach wenigstens einem der AnsprOche 1 
bis 3, wobei 

die Glyphen sich aus entsprechenden Pixelmu- 
stern zusammensetzen, die in dem Bereich in 
gekachelten, zweidimensionalen Datenzellen 



mit einer vorbestimmten GroGe gedruckt sind, 
und 

die Pixel muster im wesentlichen identische 
s Anzahlen von ON- und von OFF-Pixeln umfas- 

sen, so daB der markierte Bereich des Auf- 
zeichnungsmediums ein im wesentlichen 
gleichmaBig strukturiertes Aussehen aufweist. 

10 5. Verfahren nach Anspruch 4, wobei 

die Datenwerte einzelne Binarwerte sind, und 

sich die Glyphenformen entlang von Achsen er- 
15 strecken, die je nach den durch sie codierten 

Werten mit Winkeln von plus und minus 45° ge- 
genuber der horizontalen Achse geneigt sind. 

6. Selbsttaktender Code zum Codieren von digitalen 
20 Werten mit einer vorbestimmten Bitlange n, wobei 

der Code Glyphen umfaBt, die ausgewahlten 
der 2 n distinktiven, bezuglich der Rotation vari- 
ierenden Oder nicht variierenden, unterschetd- 
25 baren Glyphenformen entsprechen, wobei sich 

jede Glyphenform aus im wesentlichen dersel- 
ben Anzahl von ON-Pixeln zusammensetzt, 
und wobei 



30 



35 



die digitalen Werte in den Formen der Glyphen 
codiert sind, wobei die Glyphenformen in einer 
logischen Reihenfolge und in Obereinstim- 
mung mit einem vorbestimmten raumlich ver- 
teilten Muster wiedergegeben werden. 

Verfahren zum Regenerieren eines gedruckten 
selbsttaktenden Glyphenformcodes, der in Uber- 
einstimmung mit wenigstens einem der AnsprOche 
1 bis 5 codiert wurde, wobei das Verfahren folgende 
Schritte umfaBt: 

Decodieren des gedruckten Codes, um die di- 
gitalen Werte wiederzugewinnen, die in den 
Glyphenformen codiert sind, 

erneutes Codieren der digitalen Werte in den 
regenerierten Glyphenformen und 



Drucken der regenerierten Glyphenformen auf 
so einem Aufzeichnungsmedium in Obereinstim- 

mung mit dem Verfahren nach wenigstens ei- 
nem der AnsprOche 1 bis 5. 

8. Hardcopy-Aufzeichnung zum Eingeben von ma- 
ss schinenlesbarer Information in ein elektronisches 
Dokumentverarbeitungssystem, mit 

einem Hardcopy-Aufzeichnungsmedium, und 
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einem selbsttaktenden Code nach Anspruch 6, 
der auf das Aufzeichnungsmedium geschrie- 
ben ist. 



Revendications 

1. Procede de memorisation de valeurs numeriques 
de longueur en bits predetermined, n, sous un for- 
mat lisible par une machine sur un support d'enre- 10 
gistrement de copie permanente, comprenant les 
etapes consistant a : 

coder lesdites valeurs numeriques dans une 
forme correspondante parmi 2 n formes de gly- 75 
phes pouvant etre discriminees variantes ou in- 
variantes en rotation, distinctives, chaque for- 
me de glyphe etant composee pratiquement du 
meme nombre de pixels ACTIFS afin de g6r\6- 
rer un ensemble de formes de glyphes qui va- 20 
rient conformement auxdites valeurs numeri- 
ques, et 

ecrire ledit ensemble de formes de glyphes sur 
ledit support d'enregistrement suivant un ordre 
logique predetermine et conformement a un 25 
motif a distribution spatiale predeterminee afin 
de memoriser lesdites valeurs numeriques 
dans un code a autosynchronisation. 

2. Procede selon la revendication 1 , dans lequel au 30 
moins certaines desdites formes sont variantes en 
rotation. 

3. Procede selon la revendication 2, dans lequel 

lesdits glyphes sont allonges le long d'axes 35 
qui sont inclines suivant des angles de plus et moins 
45° par rapport a un axe horizontal afin de discrimi- 
ner au moins certaines desdites valeurs numeri- 
ques les unes des autres. 

40 

4. Procede selon Tune quelconque des revendications 
1 a 3, dans lequel 

lesdits glyphes sont composes de motifs de 
pixels respectifs qui sont imprimes dans ladite 45 
region dans des cellules de donnees bidimen- 
sionnetles disposees en mosaique de taille pre- 
determinee, et 

lesdits motifs de pixels comprennent des nom- 
bres pratiquement identiques de pixels ACTIFS so 
et de pixels IN ACTIFS de sorte que la region 
marquee dudit support d'enregistrement pre- 
sente un aspect a texture g6n6ralement unifor- 
me. 

55 

5. Proc6de selon la revendication 4, dans lequel 

lesdites valeurs de donnees sont des valeurs 
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binaires a un seul bit, et 
lesdites formes de glyphes sont allongees sui- 
vant des axes qui sont inclines suivant des an- 
gles de plus et moins 45° par rapport a un axe 
horizontal suivant les valeurs codees dans cel- 
les-ci. 

6. Code a autosynchronisation destine a coder des 
valeurs numeriques de longueur en bits predeter- 
minee, n, ledit code comprenant 

des glyphes se conformant a des formes se- 
lectionnees parmi 2 n formes de glyphes pouvant 
etre discriminees, variantes ou invariantes en rota- 
tion, distinctives, chaque forme de glyphe etant 
composee pratiquement du meme nombre de 
pixels ACTIFS, lesdites valeurs numeriques etant 
codees dans les formes desdits glyphes, lesdites 
formes de glyphes etant presentees suivant un or- 
dre logique et conformement a un motif a distribu- 
tion spatiale predeterminee. 

7. Procede destine a regenerer un code a formes de 
glyphes a autosynchronisation imprime qui a ete 
code conformement a Tune quelconque des reven- 
dications 1 a 5, comprenant les etapes consistant 

a: 

decoder le code imprime afin de recuperer les 
valeurs numeriques codees dans lesdites for- 
mes de glyphes, 

coder a nouveau lesdites valeurs numeriques 
en des formes de glyphes regenerees et 
imprimer lesdites formes de glyphes regene- 
rees sur un support d'enregistrement confor- 
mement au procede selon Tune quelconque 
des revendications 1 a 5. 

8. Enregistrement en copie permanente destine a sai- 
sir des informations Itsibles par une machine dans 
un systeme de traitement de document eiectroni- 
que, comprenant : 

un support d'enregistrement de copie perma- 
nente, et 

un code a autosynchronisation selon la reven- 
dication 6 ecrit sur ledit support d'enregistre- 
ment. 
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